Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

transport: implement graphql-transport-ws ws sub-protocol #1507

Merged

Conversation

jordanabderrachid
Copy link
Contributor

This implements the graphql-transport-ws websocket sub-protocol.

I have refactored the sub-protocol message parsing by creating a generic message message and a messageExchanger interface defined in the file websocket_subprotocol.go.

The previously supported graphql-ws sub-protocol is implemented in the file websocket_graphqlws.go. The new protocol is implemented in the websocket_graphql_transport_ws.go.

I've aimed to keep this change as much backward compatible as possible, the default sub-protocol selected is graphql-ws, even if the ws client does not explicitly request it. I am also not requiring the consumer of the Transport struct to provide the list of supported sub-protocols, and they are injected at runtime instead.

In addition to that, I have fixed some libraries version mismatch in the example/chat example project. I have included another implementation of the websocket link that uses the newly supported sub-protocol.

Closes #1430

I have:

  • Added tests covering the bug / feature (see testing)
  • Updated any relevant documentation (see docs)

@coveralls
Copy link

coveralls commented Apr 4, 2021

Coverage Status

Coverage increased (+0.06%) to 67.362% when pulling 07191a6 on jordanabderrachid:subscription-protocol into 28caa6c on 99designs:master.

@jordanabderrachid
Copy link
Contributor Author

It looks like the integration tests failed because of an issue with the docker registry.

 /usr/bin/docker pull golang:1.13-alpine
  Error response from daemon: Head https://registry-1.docker.io/v2/library/golang/manifests/1.13-alpine: EOF
  Warning: Docker pull failed with exit code 1, back off 6.665 seconds before retry.
  /usr/bin/docker pull golang:1.13-alpine
  Error response from daemon: Get https://registry-1.docker.io/v2/: EOF
  Warning: Docker pull failed with exit code 1, back off 2.261 seconds before retry.
  /usr/bin/docker pull golang:1.13-alpine
  Error response from daemon: Get https://registry-1.docker.io/v2/: EOF
  Error: Docker pull failed with exit code 1

Is there a way to run the tests again?

@MichaelJCompton
Copy link
Contributor

Thanks for the PR - ran tests again for you.

@audiolion
Copy link

Would be great to have this!

@zdraganov
Copy link
Contributor

zdraganov commented Aug 2, 2021

Starting from your PR, I've extended it and adding duplex ping pong option here #1578

@xiehuc
Copy link

xiehuc commented Aug 11, 2021

this would be awesome

@vitorfalcaor
Copy link

Hello, any chance this will get merged, please?

Copy link
Contributor

@jaredly jaredly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@StevenACoffman asked me to take a look at this, and it makes sense to me! I don't have much experience with graphql subscriptions though, so take it with a grain of salt. It would be nice to have an integration test that actually fired up a server and verified that the nodejs graphql-ws library can talk to it, but the included example is probably the next best thing.

example/chat/readme.md Outdated Show resolved Hide resolved
@@ -86,17 +86,21 @@ func (t Websocket) Do(w http.ResponseWriter, r *http.Request, exec graphql.Graph
}

func (c *wsConnection) init() bool {
message := c.readOp()
if message == nil {
m, err := c.me.NextMessage()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love single-character variable names

c.mu.Lock()
c.conn.WriteJSON(msg)
// TODO: missing error handling here, err from previous implementation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you make a ticket for this error handling, and then do TODO(#1234) with the issue number?

@@ -152,26 +158,27 @@ func (c *wsConnection) run() {

for {
start := graphql.Now()
message := c.readOp()
if message == nil {
m, err := c.me.NextMessage()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: variable naming

Comment on lines +47 to +50
var text string
switch t {
default:
text = "unknown"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: imo these would read better as returns

Comment on lines +306 to +307
handler.SendNextSubscriptionMessage()
msg = readOp(c)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you add a comment here about why we expect the subscription message to be received twice?

@StevenACoffman
Copy link
Collaborator

@jordanabderrachid if you can address the review from jared above and resolve the conflicts, we can get this merged! Thanks!

@frederikhors
Copy link
Collaborator

@jordanabderrachid are you still there?

@StevenACoffman
Copy link
Collaborator

@frederikhors It's been long enough that if you (or anyone) want to fork from the good work of @jordanabderrachid and make a new PR, he'll still get his credit for his original commits.

@StevenACoffman
Copy link
Collaborator

@zdraganov I rebased but I would appreciate it if in your PR you could take care of adding a comment as mentioned above describing why we expect the subscription message to be received twice. Thanks!

@StevenACoffman StevenACoffman merged commit 828820a into 99designs:master Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Will the graph-transport-ws subprotocol be implemented?